When a first electronic entity wishes to authenticate itself with a second electrical entity by proving its knowledge of a secret (in general a cryptographic key) without transmitting this secret, it is possible to undertake an exchange of challenge-response type between the two electronic entities: the second electronic entity dispatches a challenge to the first electronic entity, which, in order to authenticate itself, must send back in return an expected response associated with the challenge, typically the result of a calculation combining the challenge received and the secret.
In order to carry out mutual authentication, the first electronic entity likewise dispatches a challenge to the second electronic entity, which must determine the expected response to this other challenge and send it to the first electronic entity.
The challenges used are in general random numbers generated by the electronic entity that sent the challenge, so as to prevent an ill-intentioned third party from authenticating itself by simple repetition (sometimes dubbed “replay”) of a response sent previously by the first electronic entity.
These random values can furthermore be used, in combination with a cryptographic key known only to the two electronic entities, to generate session keys aimed at securing the exchange of data between the two electronic entities. The session keys thus generated are thus different for each session of exchanges between the two electronic entities.
However, the use of random values generated respectively in each of the two electronic entities necessitates the bidirectional exchange of data so as to successfully accomplish the process of mutual authentication and of generating the session keys (since each entity must receive the random value generated by the other entity).
To avoid this and thus allow the implementation of such processes without having to wait for an immediate return from the first electronic entity (called the “slave” hereinafter), provision has been made to use, instead of the random value generated by the first electronic entity, a so-called “pseudo-random” value, based for example on the value of a counter of the first electronic entity.
The second electronic entity (called the “master” or “host” hereinafter), which also knows the value of the counter, can thus prepare in advance the data to be dispatched (typically in the form of commands destined for the slave electronic entity), by enciphering these data by means of the session key obtained as a function in particular of the value of the counter, and transmit them in batches.
This technique is used to personalize secure electronic entities (such as microcircuit cards or secure integrated circuits) but can also be used in other contexts.
Processes such as presented hereinabove are for example described in the technical specification “GlobalPlatform Card Technology—Secure Channel Protocol 03—Card Specification v 2.2 Amendment D”, version 1.1, September 2009.
This specification provides in particular that the response of the slave electronic entity to the challenge of the host electronic entity be accompanied by the challenge generated by the slave electronic entity and intended for the host electronic entity, as is usual when mutual authentication is sought.